home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-for-bridging-01.txt < prev    next >
Text File  |  1993-10-19  |  57KB  |  1,760 lines
  1.  
  2.  
  3. Network Working Group                                      F. Baker, ACC
  4.                                                            R. Bowen, IBM
  5. Internet Draft                                                   Editors
  6. expires in six months                                       October 1993
  7.  
  8.  
  9.                   PPP Bridging Control Protocol (BCP)
  10.                  draft-ietf-pppext-for-bridging-01.txt
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This document is the product of the Point-to-Point Protocol Working
  17.    Group of the Internet Engineering Task Force (IETF).  Comments should
  18.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  19.  
  20.    Distribution of this memo is unlimited.
  21.  
  22.    This document is an Internet Draft.  Internet Drafts are working
  23.    documents of the Internet Engineering Task Force (IETF), its Areas,
  24.    and its Working Groups.  Note that other groups may also distribute
  25.    working documents as Internet Drafts.
  26.  
  27.    Internet Drafts are draft documents valid for a maximum of six
  28.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  29.    other documents at any time.  It is not appropriate to use Internet
  30.    Drafts as reference material or to cite them other than as a
  31.    ``working draft'' or ``work in progress.''
  32.  
  33.    Please check the 1id-abstracts.txt listing contained in the
  34.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  35.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  36.    current status of any Internet Draft.
  37.  
  38. Abstract
  39.  
  40.    The Point-to-Point Protocol (PPP) [6] provides a standard method for
  41.    transporting multi-protocol datagrams over point-to-point links.  PPP
  42.    defines an extensible Link Control Protocol, and proposes a family of
  43.    Network Control Protocols for establishing and configuring different
  44.    network-layer protocols.
  45.  
  46.    This document defines the Network Control Protocol for establishing
  47.    and configuring Remote Bridging for PPP links.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Baker & Bowen            expires in six months                  [Page i]
  55. DRAFT                         PPP Bridging                  October 1993
  56.  
  57.  
  58. 1.  Historical Perspective
  59.  
  60.    Two basic algorithms are ambient in the industry for Bridging of
  61.    Local Area Networks.  The more common algorithm is called
  62.    "Transparent Bridging", and has been standardized for Extended LAN
  63.    configurations by IEEE 802.1.  The other is called "Source Route
  64.    Bridging", and is prevalent on IEEE 802.5 Token Ring LANs.
  65.  
  66.    The IEEE has combined these two methods into a device called a Source
  67.    Routing Transparent (SRT) bridge, which concurrently provides both
  68.    Source Route and Transparent bridging.  Transparent and SRT bridges
  69.    are specified in IEEE standard 802.1D [3].
  70.  
  71.    Although IEEE committee 802.1G is addressing remote bridging [2],
  72.    neither standard directly defines the mechanisms for implementing
  73.    remote bridging.  Technically, that would be beyond the IEEE 802
  74.    committee's charter.  However, both 802.1D and 802.1G allow for it.
  75.    The implementor may model the line either as a component within a
  76.    single MAC Relay Entity, or as the LAN media between two remote
  77.    bridges.
  78.  
  79.  
  80. 2.  Methods of Bridging
  81.  
  82. 2.1.  Transparent Bridging
  83.  
  84.    As a favor to the uninitiated, let us first describe Transparent
  85.    Bridging.  Essentially, the bridges in a network operate as isolated
  86.    entities, largely unaware of each others' presence.  A Transparent
  87.    Bridge maintains a Forwarding Database consisting of
  88.  
  89.                            {address, interface}
  90.  
  91.    records, by saving the Source Address of each LAN transmission that
  92.    it receives, along with the interface identifier for the interface it
  93.    was received on.  It goes on to check whether the Destination Address
  94.    is in the database, and if so, either discards the message when the
  95.    destination and source are located at the same interface, or forwards
  96.    the message to the indicated interface.  A message whose Destination
  97.    Address is not found in the table is forwarded to all interfaces
  98.    except the one it was received on.  This behavior applies to
  99.    Broadcast/Multicast frames as well.
  100.  
  101.    The obvious fly in the ointment is that redundant paths in the
  102.    network cause indeterminate (nay, all too determinate) forwarding
  103.    behavior to occur.  To prevent this, a protocol called the Spanning
  104.    Tree Protocol is executed between the bridges to detect and logically
  105.    remove redundant paths from the network.
  106.  
  107.  
  108.  
  109. Baker & Bowen            expires in six months                  [Page 1]
  110. DRAFT                         PPP Bridging                  October 1993
  111.  
  112.  
  113.    One system is elected as the "Root", which periodically emits a
  114.    message called a Bridge Protocol Data Unit (BPDU), heard by all of
  115.    its neighboring bridges.  Each of these modifies and passes the BPDU
  116.    on to its neighbors, until it arrives at the leaf LAN segments in the
  117.    network (where it dies, having no further neighbors to pass it
  118.    along), or until the message is stopped by a bridge which has a
  119.    superior path to the "Root".  In this latter case, the interface the
  120.    BPDU was received on is ignored (it is placed in a Hot Standby
  121.    status, no traffic is emitted onto it except the BPDU, and all
  122.    traffic received from it is discarded), until a topology change
  123.    forces a recalculation of the network.
  124.  
  125.  
  126. 2.2.  Remote Transparent Bridging
  127.  
  128.    There exist two basic sorts of bridges -- those that interconnect
  129.    LANs directly, called Local Bridges, and those that interconnect LANs
  130.    via an intermediate medium such as a leased line, called Remote
  131.    Bridges.  PPP may be used to connect Remote Bridges.
  132.  
  133.    The IEEE 802.1G Remote MAC Bridging committee has proposed a model of
  134.    a Remote Bridge in which a set of two or more Remote Bridges that are
  135.    interconnected via remote lines are termed a Remote Bridge Group.
  136.    Within a Group, a Remote Bridge Cluster is dynamically formed through
  137.    execution of the spanning tree as the set of bridges that may pass
  138.    frames among each other.
  139.  
  140.    This model bestows on the remote lines the basic properties of a LAN,
  141.    but does not require a one-to-one mapping of lines to virtual LAN
  142.    segments.  For instance, the model of three interconnected Remote
  143.    Bridges, A, B and C, may be that of a virtual LAN segment between A
  144.    and B and another between B and C.  However, if a line exists between
  145.    Remote Bridges B and C, a frame could actually be sent directly from
  146.    B to C, as long as there was the external appearance that it had
  147.    travelled through A.
  148.  
  149.    IEEE 802.1G thus allows for a great deal of implementation freedom
  150.    for features such as route optimization and load balancing, as long
  151.    as the model is maintained.
  152.  
  153.    For simplicity and because the 802.1G proposal has not been approved
  154.    as a standard, we discuss Remote Bridging in this document in terms
  155.    of two Remote Bridges connected by a single line.  Within the 802.1G
  156.    framework, these two bridges would comprise a Remote Bridge Group.
  157.    This convention is not intended to preclude the use of PPP bridging
  158.    in larger Groups, as allowed by 802.1G.
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Baker & Bowen            expires in six months                  [Page 2]
  165. DRAFT                         PPP Bridging                  October 1993
  166.  
  167.  
  168. 2.3.  Source Routing
  169.  
  170.    The IEEE 802.1D Committee has standardized Source Routing for any MAC
  171.    Type that allows its use.  Currently, MAC Types that support Source
  172.    Routing are FDDI and IEEE 802.5 Token Ring.
  173.  
  174.    The IEEE standard defines Source Routing only as a component of an
  175.    SRT bridge.  However, many bridges have been implemented which are
  176.    capable of performing Source Routing alone.  These are most commonly
  177.    implemented in accordance either with the IBM Token-Ring Network
  178.    Architecture Reference [1] or with the Source Routing Appendix of
  179.    IEEE 802.1D [3].
  180.  
  181.    In the Source Routing approach, the originating system has the
  182.    responsibility of indicating the path that the message should follow.
  183.    It does this, if the message is directed off of the local segment, by
  184.    including a variable length MAC header extension called the Routing
  185.    Information Field (RIF).  The RIF consists of one 16-bit word of
  186.    flags and parameters, followed by zero or more segment-and-bridge
  187.    identifiers.  Each bridge en route determines from this source route
  188.    list whether it should accept the message and how to forward it.
  189.  
  190.    In order to discover the path to a destination, the originating
  191.    system transmits an Explorer frame.  An All-Routes Explorer (ARE)
  192.    frame follows all possible paths to a destination.  A Spanning Tree
  193.    Explorer (STE) frame follows only those paths defined by Bridge ports
  194.    that the Spanning Tree Algorithm has put in Forwarding state.  Port
  195.    states do not apply to ARE or Specifically-Routed Frames.  The
  196.    destination system replies to each copy of an ARE frame with a
  197.    Specifically-Routed Frame, and to an STE frame with an ARE frame.  In
  198.    either case, the originating station may receive multiple replies,
  199.    from which it chooses the route it will use for future Specifically-
  200.    Routed Frames.
  201.  
  202.    The algorithm for Source Routing requires the bridge to be able to
  203.    identify any interface by its segment-and-bridge identifier.  When a
  204.    packet is received that has the RIF present, a boolean in the RIF is
  205.    inspected to determine whether the segment-and-bridge identifiers are
  206.    to be inspected in "forward" or "reverse" sense.  In its search, the
  207.    bridge looks for the segment-and-bridge identifier of the interface
  208.    the packet was received on, and forwards the packet toward the
  209.    segment identified in the segment-and-bridge identifier that follows
  210.    it.
  211.  
  212.  
  213. 2.4.  Remote Source Route Bridging
  214.  
  215.    There is no Remote Source Route Bridge proposal in IEEE 802.1 at this
  216.  
  217.  
  218.  
  219. Baker & Bowen            expires in six months                  [Page 3]
  220. DRAFT                         PPP Bridging                  October 1993
  221.  
  222.  
  223.    time, although many vendors ship remote Source Routing Bridges.
  224.  
  225.    We allow for modelling the line either as a connection residing
  226.    between two halves of a "split" Bridge, or as a LAN segment between
  227.    two Bridges.  In the latter case, the line requires a LAN Segment ID.
  228.  
  229.    Given that source routing is configured on a line or set of lines,
  230.    the specifics of the link state with respect to STE frames are
  231.    defined by the Spanning Tree Protocol in use.
  232.  
  233.  
  234. 2.5.  SR-TB Translational Bridging
  235.  
  236.    IEEE 802 is not currently addressing bridges that translate between
  237.    Transparent Bridging and Source Routing.  For the purposes of this
  238.    standard, such a device is either a Transparent or a Source Routing
  239.    bridge, and will act on the line in one of these two ways, just as it
  240.    does on the LAN.
  241.  
  242.  
  243. 3.  Traffic Services
  244.  
  245.    Several services are provided for the benefit of different system
  246.    types and user configurations.  These include LAN Frame Checksum
  247.    Preservation, LAN Frame Checksum Generation, Tinygram Compression,
  248.    and the identification of closed sets of LANs.
  249.  
  250.  
  251. 3.1.  LAN Frame Checksum Preservation
  252.  
  253.    IEEE 802.1 stipulates that the Extended LAN must enjoy the same
  254.    probability of undetected error that an individual LAN enjoys.
  255.    Although there has been considerable debate concerning the algorithm,
  256.    no other algorithm has been proposed than having the LAN Frame
  257.    Checksum received by the ultimate receiver be the same value
  258.    calculated by the original transmitter.  Achieving this requires, of
  259.    course, that the line protocols preserve the LAN Frame Checksum from
  260.    end to end.  The protocol is optimized towards this approach.
  261.  
  262.  
  263. 3.2.  Traffic having no LAN Frame Checksum
  264.  
  265.    The fact that the protocol is optimized towards LAN Frame Checksum
  266.    preservation raises twin questions: "What is the approach to be used
  267.    by systems which, for whatever reason, cannot easily support Frame
  268.    Checksum preservation?" and "What is the approach to be used when the
  269.    system originates a message, which therefore has no Frame Checksum
  270.    precalculated?".
  271.  
  272.  
  273.  
  274. Baker & Bowen            expires in six months                  [Page 4]
  275. DRAFT                         PPP Bridging                  October 1993
  276.  
  277.  
  278.    Surely, one approach would be to require stations to calculate the
  279.    Frame Checksum in software if hardware support were unavailable; this
  280.    would meet with profound dismay, and would raise serious questions of
  281.    interpretation in a Bridge/Router.
  282.  
  283.    However, stations which implement LAN Frame Checksum preservation
  284.    must already solve this problem, as they do originate traffic.
  285.    Therefore, the solution adopted is that messages which have no Frame
  286.    Checksum are tagged and carried across the line.
  287.  
  288.    When a system which does not implement LAN Frame Checksum
  289.    preservation receives a frame having an embedded FCS, it converts it
  290.    for its own use by removing the trailing four octets.  When any
  291.    system forwards a frame which contains no embedded FCS to a LAN, it
  292.    forwards it in a way which causes the FCS to be calculated.
  293.  
  294.  
  295. 3.3.  Tinygram Compression
  296.  
  297.    An issue in remote Ethernet bridging is that the protocols that are
  298.    most attractive to bridge are prone to problems on low speed (64 KBPS
  299.    and below) lines.  This can be partially alleviated by observing that
  300.    the vendors defining these protocols often fill the PDU with octets
  301.    of ZERO.  Thus, an Ethernet or IEEE 802.3 PDU received from a line
  302.    that is (1) smaller than the minimum PDU size, and (2) has a LAN
  303.    Frame Checksum present, must be padded by inserting zeroes between
  304.    the last four octets and the rest of the PDU before transmitting it
  305.    on a LAN.  These protocols are frequently used for interactive
  306.    sessions, and therefore are frequently this small.
  307.  
  308.    To prevent ambiguity, PDUs requiring padding are explicitly tagged.
  309.    Compression is at the option of the transmitting station, and is
  310.    probably performed only on low speed lines, perhaps under
  311.    configuration control.
  312.  
  313.    The pseudo-code in Appendix 1 describes the algorithms.
  314.  
  315.  
  316. 3.4.  LAN Identification
  317.  
  318.    In some applications, it is useful to tag traffic by the user
  319.    community it is a part of, and guarantee that it will be only emitted
  320.    onto a LAN which is of the same community.  The user community is
  321.    defined by a LAN ID.  Systems which choose to not implement this
  322.    feature must assume that any frame received having a LAN ID is from a
  323.    different community than theirs, and discard it.
  324.  
  325.    It should be noted that the enabling of the LAN Identification option
  326.  
  327.  
  328.  
  329. Baker & Bowen            expires in six months                  [Page 5]
  330. DRAFT                         PPP Bridging                  October 1993
  331.  
  332.  
  333.    requires behavior consistent with the following additions to the
  334.    standard bridging algorithm.
  335.  
  336.    Each bridge port may be considered to have two additional variables
  337.    associated with it: "domain" and "checkDomain".
  338.  
  339.    The variable "domain" (a 32-bit unsigned integer) is assigned a value
  340.    that uniquely labels a set of bridge ports in an extended network,
  341.    with a default value of 1, and the values of 0 and 0xffffffff being
  342.    reserved.
  343.  
  344.    The variable "checkDomain" (a boolean) controls whether this value is
  345.    used to filter output to a bridge port.  The variable "checkDomain"
  346.    is generally set to the boolean value True for LAN bridge ports, and
  347.    set to the boolean value False for WAN bridge ports.
  348.  
  349.    The action of the bridge is then as modified as expressed in the
  350.    following C code fragments:
  351.  
  352.       On a packet being received from a bridge port:
  353.  
  354.       if (domainNotPresentWithPacket) {
  355.           packetInformation.domain = portInformation[inputPort].domain;
  356.       } else {
  357.           packetInformation.domain = domainPresentWithPacket;
  358.       }
  359.  
  360.       On a packet being transmitted from a bridge port:
  361.  
  362.       if (portInformation[outputPort].checkDomain &&
  363.           portInformation[outputPort] != packetInformation.domain) {
  364.           discardPacket();
  365.           return;
  366.       }
  367.  
  368.    For example, suppose you have the following configuration:
  369.  
  370.            E1     +--+            +--+     E3
  371.       ------------|  |            |  |------------
  372.                   |  |     W1     |  |
  373.                   |B1|------------|B2|
  374.            E2     |  |            |  |     E4
  375.       ------------|  |            |  |------------
  376.                   +--+            +--+
  377.  
  378.    E1, E2, E3, and E4 are Ethernet LANs (or Token Ring, FDDI, etc.).  W1
  379.    is a WAN (PPP over T1).  B1 and B2 are MAC level bridges.
  380.  
  381.  
  382.  
  383.  
  384. Baker & Bowen            expires in six months                  [Page 6]
  385. DRAFT                         PPP Bridging                  October 1993
  386.  
  387.  
  388.    You want End Stations on E1 and E3 to communicate, and you want End
  389.    Stations on E2 and E4 to communicate, but you do not want End
  390.    Stations on E1 and E3 to communicate with End Stations on E2 and E4.
  391.    This is true for Unicast, Multicast, and Broadcast traffic.  If a
  392.    broadcast datagram originates on E1, you want it only to be
  393.    propagated to E3, and not on E2 or E4.
  394.  
  395.    Another way of looking at it is that E1 and E3 form a Virtual LAN,
  396.    and E2 and E4 form a Virtual LAN, as if the following configuration
  397.    were actually being used:
  398.  
  399.            E1     +--+     W2     +--+     E3
  400.       ------------|B3|------------|B4|------------
  401.                   +--+            +--+
  402.  
  403.            E2     +--+     W3     +--+     E4
  404.       ------------|B5|------------|B6|------------
  405.                   +--+            +--+
  406.  
  407.    To accomplish this (using the LAN Identification option), B1 and B2
  408.    negotiate this option on, and send datagrams with bit 6 set to 1,
  409.    with the LAN ID field inserted in the frame.  Traffic on E1 and E3
  410.    would be assigned LAN ID 1, and traffic on E2 and E4 would be
  411.    assigned LAN ID 2.  Thus B1 and B2 can separate traffic going over
  412.    W1.
  413.  
  414.    Note that execution of the spanning tree algorithm may result in the
  415.    subdivision of a domain.  The administrator of LAN domains must
  416.    ensure, through spanning tree configuration and topology design, that
  417.    such subdivision does not occur.
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439. Baker & Bowen            expires in six months                  [Page 7]
  440. DRAFT                         PPP Bridging                  October 1993
  441.  
  442.  
  443. 4.  A PPP Network Control Protocol for Bridging
  444.  
  445.    The Bridging Control Protocol (BCP) is responsible for configuring,
  446.    enabling and disabling the bridge protocol modules on both ends of
  447.    the point-to-point link.  BCP uses the same packet exchange mechanism
  448.    as the Link Control Protocol.  BCP packets may not be exchanged until
  449.    PPP has reached the Network-Layer Protocol phase.  BCP packets
  450.    received before this phase is reached SHOULD be silently discarded.
  451.  
  452.    The Bridging Control Protocol is exactly the same as the Link Control
  453.    Protocol [6] with the following exceptions:
  454.  
  455.    Frame Modifications
  456.  
  457.       The packet may utilize any modifications to the basic frame format
  458.       which have been negotiated during the Link Establishment phase.
  459.  
  460.       Implementations SHOULD NOT negotiate Address-and-Control-Field-
  461.       Compression or Protocol-Field-Compression on other than low speed
  462.       links.
  463.  
  464.    Data Link Layer Protocol Field
  465.  
  466.       Exactly one BCP packet is encapsulated in the PPP Information
  467.       field, where the PPP Protocol field indicates type hex 8031 (BCP).
  468.  
  469.    Code field
  470.  
  471.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  472.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  473.       and Code-Reject) are used.  Other Codes SHOULD be treated as
  474.       unrecognized and SHOULD result in Code-Rejects.
  475.  
  476.    Timeouts
  477.  
  478.       BCP packets may not be exchanged until PPP has reached the
  479.       Network-Layer Protocol phase.  An implementation SHOULD be
  480.       prepared to wait for Authentication and Link Quality Determination
  481.       to finish before timing out waiting for a Configure-Ack or other
  482.       response.  It is suggested that an implementation give up only
  483.       after user intervention or a configurable amount of time.
  484.  
  485.    Configuration Option Types
  486.  
  487.       BCP has a distinct set of Configuration Options, which are defined
  488.       in this document.
  489.  
  490.  
  491.  
  492.  
  493.  
  494. Baker & Bowen            expires in six months                  [Page 8]
  495. DRAFT                         PPP Bridging                  October 1993
  496.  
  497.  
  498. 4.1.  Sending Bridge Frames
  499.  
  500.    Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST
  501.    reach the Network-Layer Protocol phase, and the Bridging Control
  502.    Protocol MUST reach the Opened state.
  503.  
  504.    Exactly one Bridged LAN Traffic or BPDU is encapsulated in the PPP
  505.    Information field, where the PPP Protocol field indicates type hex
  506.    0031 (Bridged PDU).
  507.  
  508.  
  509. 4.1.1.  Maximum Receive Unit Considerations
  510.  
  511.    The maximum length of a Bridged datagram transmitted over a PPP link
  512.    is the same as the maximum length of the Information field of a PPP
  513.    encapsulated packet.  Since there is no standard method for
  514.    fragmenting and reassembling Bridged PDUs, PPP links supporting
  515.    Bridging MUST negotiate an MRU large enough to support the MAC Types
  516.    that are later negotiated for Bridging support.  Because they include
  517.    the MAC headers, even bridged Ethernet frames are larger than the
  518.    default PPP MRU of 1500 octets.
  519.  
  520.  
  521. 4.1.2.  Loopback and Link Quality Monitoring
  522.  
  523.    It is strongly recommended that PPP Bridge Protocol implementations
  524.    utilize Magic Number Loopback Detection and Link-Quality-Monitoring.
  525.    The 802.1 Spanning Tree protocol, which is integral to both
  526.    Transparent Bridging and Source Routing (as standardized), is
  527.    unidirectional during normal operation.  Configuration BPDUs emanate
  528.    from the Root system in the general direction of the leaves, without
  529.    any reverse traffic except in response to network events.
  530.  
  531.  
  532. 4.1.3.  Message Sequence
  533.  
  534.    The multiple link case requires consideration of message
  535.    sequentiality.  The transmitting system may determine either that the
  536.    protocol being bridged requires transmissions to arrive in the order
  537.    of their original transmission, and enqueue all transmissions on a
  538.    given conversation onto the same link to force order preservation, or
  539.    that the protocol does NOT require transmissions to arrive in the
  540.    order of their original transmission, and use that knowledge to
  541.    optimize the utilization of several links, enqueuing traffic to
  542.    multiple links to minimize delay.
  543.  
  544.    In the absence of such a determination, the transmitting system MUST
  545.    act as though all protocols require order preservation.  Many
  546.  
  547.  
  548.  
  549. Baker & Bowen            expires in six months                  [Page 9]
  550. DRAFT                         PPP Bridging                  October 1993
  551.  
  552.  
  553.    protocols designed primarily for use on a single LAN require order
  554.    preservation.
  555.  
  556.    Work is currently in progress on a protocol to allow use of multiple
  557.    PPP links [7].  If approved, this protocol will allow use of multiple
  558.    links while maintaining message sequentiality for Bridged LAN Traffic
  559.    and BPDU frames.
  560.  
  561.  
  562. 4.1.4.  Separation of Spanning Tree Domains
  563.  
  564.    It is conceivable that a network manager might wish to inhibit the
  565.    exchange of BPDUs on a link in order to logically divide two regions
  566.    into separate Spanning Trees with different Roots (and potentially
  567.    different Spanning Tree implementations or algorithms).  In order to
  568.    do that, he should configure both ends to not exchange BPDUs on a
  569.    link.  An implementation that does not support any spanning tree
  570.    protocol MUST silently discard any received IEEE 802.1D BPDU packets,
  571.    and MUST either silently discard or respond to other received BPDU
  572.    packets with an LCP Protocol-Reject packet.
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604. Baker & Bowen            expires in six months                 [Page 10]
  605. DRAFT                         PPP Bridging                  October 1993
  606.  
  607.  
  608. 4.2.  Bridged LAN Traffic
  609.  
  610.    For Bridging LAN traffic, the format of the frame on the line is
  611.    shown below.  The fields are transmitted from left to right.
  612.  
  613.    802.3 Frame format
  614.  
  615.     0                   1                   2                   3
  616.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  617.    +-+-+-+-+-+-+-+-+
  618.    |   HDLC FLAG   |
  619.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  620.    |      Address and Control      |      0x00     |      0x31     |
  621.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  622.    |F|I|Z|0| Pads  |    MAC Type   |  LAN ID high word (optional)  |
  623.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  624.    |   LAN ID low word (optional)  |      Destination MAC Address  |
  625.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  626.    |                       Destination MAC Address                 |
  627.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  628.    |                       Source MAC Address                      |
  629.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  630.    |     Source MAC Address        |      Length/Type              |
  631.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  632.    |               LLC data       ...
  633.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  634.    |                   LAN FCS (optional)                          |
  635.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  636.    |                potential line protocol pad                    |
  637.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  638.    |          Frame FCS            |   HDLC FLAG   |
  639.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659. Baker & Bowen            expires in six months                 [Page 11]
  660. DRAFT                         PPP Bridging                  October 1993
  661.  
  662.  
  663.  
  664.    802.4/802.5/FDDI Frame format
  665.  
  666.     0                   1                   2                   3
  667.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  668.    +-+-+-+-+-+-+-+-+
  669.    |   HDLC FLAG   |
  670.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  671.    |      Address and Control      |      0x00     |      0x31     |
  672.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  673.    |F|I|Z|0| Pads  |    MAC Type   |  LAN ID high word (optional)  |
  674.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  675.    |   LAN ID low word (optional)  |   Pad Byte    | Frame Control |
  676.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  677.    |                       Destination MAC Address                 |
  678.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  679.    |     Destination MAC Address   |  Source MAC Address           |
  680.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  681.    |                       Source MAC Address                      |
  682.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  683.    |               LLC data       ...
  684.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  685.    |                   LAN FCS (optional)                          |
  686.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  687.    |              optional Data Link Layer padding                 |
  688.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  689.    |          Frame FCS            |   HDLC FLAG   |
  690.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  691.  
  692.  
  693.    Address and Control
  694.  
  695.       As defined by the framing in use.
  696.  
  697.    PPP Protocol
  698.  
  699.       0x0031 for PPP Bridging
  700.  
  701.    Flags
  702.  
  703.  
  704.       bit F:  Set if the LAN FCS Field is present
  705.       bit I:  Set if the LAN ID Field is present
  706.       bit Z:  Set if IEEE 802.3 Pad must be zero filled to minimum size
  707.       bit 0:  reserved, must be zero
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714. Baker & Bowen            expires in six months                 [Page 12]
  715. DRAFT                         PPP Bridging                  October 1993
  716.  
  717.  
  718.    Pads
  719.  
  720.       Any PPP frame may have padding inserted in the "Optional Data Link
  721.       Layer Padding" field.  This number tells the receiving system how
  722.       many pad octets to strip off.
  723.  
  724.    MAC Type
  725.  
  726.       Up-to-date values of the MAC Type field are specified in the most
  727.       recent "Assigned Numbers" RFC [4].  Current values are assigned as
  728.       follows:
  729.  
  730.           0: reserved
  731.           1: IEEE 802.3/Ethernet  with canonical addresses
  732.           2: IEEE 802.4           with non-canonical addresses
  733.           3: IEEE 802.5           with non-canonical addresses
  734.           4: FDDI                 with non-canonical addresses
  735.         5-9: reserved
  736.          10: IEEE 802.4           with canonical addresses
  737.          11: IEEE 802.5           with canonical addresses
  738.          12: FDDI                 with canonical addresses
  739.  
  740.       "Canonical" is the address format defined as standard address
  741.       representation by the IEEE.  In this format, the bit within each
  742.       byte that is to be transmitted first on a LAN is represented as
  743.       the least significant bit.  In contrast, in non-canonical form,
  744.       the bit within each byte that is to be transmitted first is
  745.       represented as the most-significant bit.  Many LAN interface
  746.       implementations use non-canonical form.  In both formats, bytes
  747.       are represented in the order of transmission.
  748.  
  749.       Restriction:  If an implementation supports a MAC Type that is the
  750.       higher-numbered format of that MAC Type, then it MUST also support
  751.       the lower-numbered format of that MAC Type.  For example, if an
  752.       implementation supports FDDI with canonical address format, then
  753.       it MUST also support FDDI with non-canonical address format.  The
  754.       purpose of this requirement is to provide backward compatibility
  755.       with earlier versions of this specification.
  756.  
  757.    LAN ID
  758.  
  759.       This optional 32-bit field identifies the Community of LANs which
  760.       may be interested to receive this frame.  If the LAN ID flag is
  761.       not set, then this field is not present, and the PDU is four
  762.       octets shorter.
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769. Baker & Bowen            expires in six months                 [Page 13]
  770. DRAFT                         PPP Bridging                  October 1993
  771.  
  772.  
  773.    Frame Control
  774.  
  775.       On 802.4, 802.5, and FDDI LANs, there are a few octets preceding
  776.       the Destination MAC Address, one of which is protected by the FCS.
  777.  
  778.       The MAC Type of the frame determines the contents of the Frame
  779.       Control field.  A pad octet is present to provide 32-bit packet
  780.       alignment.
  781.  
  782.    Destination MAC Address
  783.  
  784.       As defined by the IEEE.  The MAC Type field defines the bit
  785.       ordering.
  786.  
  787.    Source MAC Address
  788.  
  789.       As defined by the IEEE.  The MAC Type field defines the bit
  790.       ordering.
  791.  
  792.    LLC data
  793.  
  794.       This is the remainder of the MAC frame which is (or would be were
  795.       it present) protected by the LAN FCS.
  796.  
  797.       For example, the 802.5 Access Control field, and Status Trailer
  798.       are not meaningful to transmit to another ring, and are omitted.
  799.  
  800.    LAN FCS
  801.  
  802.       If present, this is the LAN FCS which was calculated by (or which
  803.       appears to have been calculated by) the originating station.  If
  804.       the LAN FCS flag is not set, then this field is not present, and
  805.       the PDU is four octets shorter.
  806.  
  807.    Optional Data Link Layer Padding
  808.  
  809.       Any PPP frame may have padding inserted between the Information
  810.       field and the Frame FCS.  The Pads field contains the length of
  811.       this padding, which may not exceed 15 octets.
  812.  
  813.       The PPP LCP Extensions [5] specify a self-describing pad.
  814.       Implementations are encouraged to set the Pads field to zero, and
  815.       use the self-describing pad instead.
  816.  
  817.    Frame FCS
  818.  
  819.       Mentioned primarily for clarity.  The FCS used on the PPP link is
  820.       separate from and unrelated to the LAN FCS.
  821.  
  822.  
  823.  
  824. Baker & Bowen            expires in six months                 [Page 14]
  825. DRAFT                         PPP Bridging                  October 1993
  826.  
  827.  
  828. 4.3.  Spanning Tree Bridge PDU
  829.  
  830.    This is the Spanning Tree BPDU, without any MAC or 802.2 LLC header
  831.    (these being functionally equivalent to the Address, Control, and PPP
  832.    Protocol Fields).  The LAN Pad and Frame Checksum fields are likewise
  833.    superfluous and absent.
  834.  
  835.    The Address and Control Fields are subject to LCP Address-and-
  836.    Control-Field-Compression negotiation.
  837.  
  838.    A PPP system which is configured to participate in a particular
  839.    spanning tree protocol and receives a BPDU of a different spanning
  840.    tree protocol SHOULD reject it with the LCP Protocol-Reject.  A
  841.    system which is configured not to participate in any spanning tree
  842.    protocol MUST silently discard all BPDUs.
  843.  
  844.    Spanning Tree Bridge PDU
  845.  
  846.     0                   1                   2                   3
  847.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  848.    +-+-+-+-+-+-+-+-+
  849.    |   HDLC FLAG   |
  850.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  851.    |      Address and Control      |     Spanning Tree Protocol    |
  852.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  853.    |              BPDU data       ...                              |
  854.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  855.    |          Frame FCS            |   HDLC FLAG   |
  856.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  857.  
  858.  
  859.    Address and Control
  860.  
  861.       As defined by the framing in use.
  862.  
  863.    Spanning Tree Protocol
  864.  
  865.       Up-to-date values of the Spanning-Tree-Protocol field are
  866.       specified in the most recent "Assigned Numbers" RFC [4].  Current
  867.       values are assigned as follows:
  868.  
  869.  
  870.          Value (in hex)  Protocol
  871.  
  872.          0201            IEEE 802.1 (either 802.1D or 802.1G)
  873.          0203            IBM Source Route Bridge
  874.  
  875.       The two versions of the IEEE 802.1 spanning tree protocol frames
  876.  
  877.  
  878.  
  879. Baker & Bowen            expires in six months                 [Page 15]
  880. DRAFT                         PPP Bridging                  October 1993
  881.  
  882.  
  883.       can be distinguished by fields within the BPDU data.
  884.  
  885.    BPDU data
  886.  
  887.       As defined by the specified Spanning Tree Protocol.
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934. Baker & Bowen            expires in six months                 [Page 16]
  935. DRAFT                         PPP Bridging                  October 1993
  936.  
  937.  
  938. 5.  BCP Configuration Options
  939.  
  940. BCP Configuration Options allow modifications to the standard
  941. characteristics of the network-layer protocol to be negotiated.  If a
  942. Configuration Option is not included in a Configure-Request packet, the
  943. default value for that Configuration Option is assumed.
  944.  
  945. BCP uses the same Configuration Option format defined for LCP [6], with
  946. a separate set of Options.
  947.  
  948. Up-to-date values of the BCP Option Type field are specified in the most
  949. recent "Assigned Numbers" RFC [4].  Current values are assigned as
  950. follows:
  951.  
  952.  
  953.    1       Bridge-Identification
  954.    2       Line-Identification
  955.    3       MAC-Support
  956.    4       Tinygram-Compression
  957.    5       LAN-Identification
  958.    6       MAC-Address
  959.    7       Spanning-Tree-Protocol
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989. Baker & Bowen            expires in six months                 [Page 17]
  990. DRAFT                         PPP Bridging                  October 1993
  991.  
  992.  
  993. 5.1.  Bridge-Identification
  994.  
  995.    Description
  996.  
  997.       The Bridge-Identification Configuration Option is designed for use
  998.       when the line is an interface between half bridges connecting
  999.       virtual or physical LAN segments.  Since these remote bridges are
  1000.       modeled as a single bridge with a strange internal interface, each
  1001.       remote bridge needs to know the LAN segment and bridge numbers of
  1002.       the adjacent remote bridge.
  1003.  
  1004.       The Source Routing Route Descriptor and its use are specified by
  1005.       the IEEE 802.1D Appendix on Source Routing.  It identifies the
  1006.       segment to which the interface is attached by its configured
  1007.       segment number, and itself by bridge number on the segment.
  1008.  
  1009.       The two half bridges MUST agree on the bridge number.  When the
  1010.       two disagree, the larger of the two numbers SHOULD be used.  To
  1011.       resolve the conflict, the system with the higher bridge number
  1012.       SHOULD Configure-Nak the option, suggesting its own bridge number
  1013.       for use.  If a bridge number is not agreed upon, the Bridging
  1014.       Control Protocol MUST NOT enter the Opened state.
  1015.  
  1016.       By default, a system that does not negotiate this option is
  1017.       assumed not to support the model of the two systems as two halves
  1018.       of a single source-route bridge.
  1019.  
  1020.    Example
  1021.  
  1022.       If System A announces LAN Segment AAA, Bridge #1, and System B
  1023.       announces LAN Segment BBB, Bridge #1, then the resulting Source
  1024.       Routing configuration (read in the appropriate direction) is then
  1025.       AAA,1,BBB.
  1026.  
  1027.    A summary of the Bridge-Identification Option format is shown below.
  1028.    The fields are transmitted from left to right.
  1029.  
  1030.     0                   1                   2                   3
  1031.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1032.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1033.    |     Type      |    Length     | LAN Segment Number    |Bridge#|
  1034.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1035.  
  1036.  
  1037.    Type
  1038.  
  1039.       1
  1040.  
  1041.  
  1042.  
  1043.  
  1044. Baker & Bowen            expires in six months                 [Page 18]
  1045. DRAFT                         PPP Bridging                  October 1993
  1046.  
  1047.  
  1048.    Length
  1049.  
  1050.       4
  1051.  
  1052.    LAN Segment Number
  1053.  
  1054.       A 12-bit number identifying the LAN segment, as defined in the
  1055.       IEEE 802.1D Source Routing Specification.
  1056.  
  1057.    Bridge Number
  1058.  
  1059.       A 4-bit number identifying the bridge on the LAN segment, as
  1060.       defined in the IEEE 802.1D Source Routing Specification.
  1061.  
  1062.  
  1063. 5.2.  Line-Identification
  1064.  
  1065.    Description
  1066.  
  1067.       The Line-Identification Configuration Option is designed for use
  1068.       when the line is assigned a LAN segment number as though it were a
  1069.       two system LAN segment in accordance with the Source Routing
  1070.       algorithm.
  1071.  
  1072.       The Source Routing Route Descriptor and its use are specified by
  1073.       the IEEE 802.1D Appendix on Source Routing.  It identifies the
  1074.       segment to which the interface is attached by its configured
  1075.       segment number, and itself by bridge number on the segment.
  1076.  
  1077.       The two bridges MUST agree on the LAN segment number.  When the
  1078.       two disagree, the larger of the two numbers SHOULD be used.  To
  1079.       resolve the conflict, the system with the higher LAN segment
  1080.       number SHOULD Configure-Nak the option, suggesting its own LAN
  1081.       segment number for use.  If a LAN segment number is not agreed
  1082.       upon, the Bridging Control Protocol MUST NOT enter the Opened
  1083.       state.
  1084.  
  1085.       By default, a system that does not negotiate this option is
  1086.       assumed not to support the model of the two systems as two
  1087.       source-route bridges with the line serving as a LAN segment
  1088.       between them.
  1089.  
  1090.    A summary of the Line-Identification Option format is shown below.
  1091.    The fields are transmitted from left to right.
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099. Baker & Bowen            expires in six months                 [Page 19]
  1100. DRAFT                         PPP Bridging                  October 1993
  1101.  
  1102.  
  1103.  
  1104.     0                   1                   2                   3
  1105.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1106.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1107.    |     Type      |    Length     | LAN Segment Number    |Bridge#|
  1108.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1109.  
  1110.  
  1111.    Type
  1112.  
  1113.       2
  1114.  
  1115.    Length
  1116.  
  1117.       4
  1118.  
  1119.    LAN Segment Number
  1120.  
  1121.       A 12-bit number identifying the LAN segment, as defined in the
  1122.       IEEE 802.1D Source Routing Specification.
  1123.  
  1124.    Bridge Number
  1125.  
  1126.       A 4-bit number identifying the bridge on the LAN segment, as
  1127.       defined in the IEEE 802.1D Source Routing Specification.
  1128.  
  1129.  
  1130. 5.3.  MAC-Support
  1131.  
  1132.    Description
  1133.  
  1134.       The MAC-Support Configuration Option is provided to permit
  1135.       implementations to indicate the sort of traffic they are prepared
  1136.       to receive.
  1137.  
  1138.       By default, when an implementation does not announce the MAC Types
  1139.       that it supports, all MAC Types are sent by the peer which are
  1140.       capable of being transported given other configuration parameters.
  1141.       The receiver will discard those MAC Types that it does not
  1142.       support.
  1143.  
  1144.       A device supporting a 1600 octet MRU might not be willing to
  1145.       support 802.5, 802.4 or FDDI, which each support frames larger
  1146.       than 1600 octets.
  1147.  
  1148.       By announcing the MAC Types it will support, an implementation is
  1149.       advising its peer that all unspecified MAC Types will be
  1150.       discarded.  The peer MAY then reduce bandwidth usage by not
  1151.  
  1152.  
  1153.  
  1154. Baker & Bowen            expires in six months                 [Page 20]
  1155. DRAFT                         PPP Bridging                  October 1993
  1156.  
  1157.  
  1158.       sending the unsupported MAC Types.
  1159.  
  1160.       Announcement of support for multiple MAC Types is accomplished by
  1161.       placing multiple options in the Configure-Request.
  1162.  
  1163.       The nature of this option is advisory only.  This option MUST NOT
  1164.       be included in a Configure-Nak.
  1165.  
  1166.    A summary of the MAC-Support Option format is shown below.  The
  1167.    fields are transmitted from left to right.
  1168.  
  1169.     0                   1                   2
  1170.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  1171.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1172.    |     Type      |    Length     |    MAC Type   |
  1173.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1174.  
  1175.  
  1176.    Type
  1177.  
  1178.       3
  1179.  
  1180.    Length
  1181.  
  1182.       3
  1183.  
  1184.    MAC Type
  1185.  
  1186.       One of the values of the PDU MAC Type field (previously described
  1187.       in the "Common LAN Traffic" section) that this system is prepared
  1188.       to receive and service.
  1189.  
  1190.  
  1191. 5.4.  Tinygram-Compression
  1192.  
  1193.    Description
  1194.  
  1195.       This Configuration Option permits the implementation to indicate
  1196.       support for Tinygram compression.
  1197.  
  1198.       Not all systems are prepared to make modifications to messages in
  1199.       transit.  On high speed lines, it is probably not worth the
  1200.       effort.
  1201.  
  1202.       A Configure-NAK MUST NOT be sent in response to a Configure-
  1203.       Request that includes this option.
  1204.  
  1205.       By default, no compression is allowed.  A system which does not
  1206.  
  1207.  
  1208.  
  1209. Baker & Bowen            expires in six months                 [Page 21]
  1210. DRAFT                         PPP Bridging                  October 1993
  1211.  
  1212.  
  1213.       negotiate, or negotiates this option to be disabled, should never
  1214.       receive a compressed packet.
  1215.  
  1216.    A summary of the Tinygram-Compression Option format is shown below.
  1217.    The fields are transmitted from left to right.
  1218.  
  1219.     0                   1                   2
  1220.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  1221.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1222.    |     Type      |    Length     | Enable/Disable|
  1223.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1224.  
  1225.  
  1226.    Type
  1227.  
  1228.       4
  1229.  
  1230.    Length
  1231.  
  1232.       3
  1233.  
  1234.    Enable/Disable
  1235.  
  1236.       If the value is 1, Tinygram-Compression is enabled.  If the value
  1237.       is 2, Tinygram-Compression is disabled, and no decompression will
  1238.       occur.
  1239.  
  1240.       The implementations need not agree on the setting of this
  1241.       parameter.  One may be willing to decompress and the other not.
  1242.  
  1243.  
  1244. 5.5.  LAN-Identification
  1245.  
  1246.    Description
  1247.  
  1248.       This Configuration Option permits the implementation to indicate
  1249.       support for the LAN Identification field, and that the system is
  1250.       prepared to service traffic to any labeled LANs beyond the system.
  1251.  
  1252.       A Configure-NAK MUST NOT be sent in response to a Configure-
  1253.       Request that includes this option.
  1254.  
  1255.       By default, LAN-Identification is disabled.  All Bridge LAN
  1256.       Traffic and BPDUs that contain the LAN ID field will be discarded.
  1257.       The peer may then reduce bandwidth usage by not sending the
  1258.       unsupported traffic.
  1259.  
  1260.    A summary of the LAN-Identification Option format is shown below.
  1261.  
  1262.  
  1263.  
  1264. Baker & Bowen            expires in six months                 [Page 22]
  1265. DRAFT                         PPP Bridging                  October 1993
  1266.  
  1267.  
  1268.    The fields are transmitted from left to right.
  1269.  
  1270.     0                   1                   2
  1271.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  1272.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1273.    |     Type      |    Length     | Enable/Disable|
  1274.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1275.  
  1276.  
  1277.    Type
  1278.  
  1279.       5
  1280.  
  1281.    Length
  1282.  
  1283.       3
  1284.  
  1285.    Enable/Disable
  1286.  
  1287.       If the value is 1, LAN Identification is enabled.  If the value is
  1288.       2, LAN Identification is disabled.
  1289.  
  1290.       The implementations need not agree on the setting of this
  1291.       parameter.  One may be willing to accept LAN Identification and
  1292.       the other not.
  1293.  
  1294.  
  1295. 5.6.  MAC-Address
  1296.  
  1297.    Description
  1298.  
  1299.       The MAC-Address Configuration Option enables the implementation to
  1300.       announce its MAC address or have one assigned.  The MAC address is
  1301.       represented in IEEE 802.1 Canonical format, which is to say that
  1302.       the multicast bit is the least significant bit of the first octet
  1303.       of the address.
  1304.  
  1305.       If the system wishes to announce its MAC address, it sends the
  1306.       option with its MAC address specified.  When specifying a non-zero
  1307.       MAC address in a Configure-Request, any inclusion of this option
  1308.       in a Configure-Nak MUST be ignored.
  1309.  
  1310.       If the implementation wishes to have a MAC address assigned, it
  1311.       sends the option with a MAC address of 00-00-00-00-00-00.  Systems
  1312.       that have no mechanism for address assignment will Configure-
  1313.       Reject the option.
  1314.  
  1315.       A Configure-Nak MUST specify a valid IEEE 802.1 format physical
  1316.  
  1317.  
  1318.  
  1319. Baker & Bowen            expires in six months                 [Page 23]
  1320. DRAFT                         PPP Bridging                  October 1993
  1321.  
  1322.  
  1323.       address; the multicast bit MUST be zero.  It is strongly
  1324.       recommended (although not mandatory) that the "locally assigned
  1325.       address" bit (the second least significant bit in the first octet)
  1326.       be set, indicating a locally assigned address.
  1327.  
  1328.    A summary of the MAC-Address Option format is shown below.  The
  1329.    fields are transmitted from left to right.
  1330.  
  1331.     0                   1                   2                   3
  1332.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1333.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1334.    |     Type      |    Length     |MAC byte 1 |L|M|  MAC byte 2   |
  1335.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1336.    |  MAC byte 3   |  MAC byte 4   |  MAC byte 5   |  MAC byte 6   |
  1337.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1338.  
  1339.  
  1340.    Type
  1341.  
  1342.       6
  1343.  
  1344.    Length
  1345.  
  1346.       8
  1347.  
  1348.    MAC Byte
  1349.  
  1350.       Six octets of MAC address in 802.1 Canonical order.  For clarity,
  1351.       the position of the Local Assignment (L) and Multicast (M) bits
  1352.       are shown in the diagram.
  1353.  
  1354.  
  1355. 5.7.  Spanning-Tree-Protocol
  1356.  
  1357.    Description
  1358.  
  1359.       The Spanning-Tree-Protocol Configuration Option enables the
  1360.       Bridges to negotiate the version of the spanning tree protocol in
  1361.       which they will participate.
  1362.  
  1363.       If both bridges support a spanning tree protocol, they MUST agree
  1364.       on the protocol to be supported.  When the two disagree, the
  1365.       lower-numbered of the two spanning tree protocols should be used.
  1366.       To resolve the conflict, the system with the lower-numbered
  1367.       protocol SHOULD Configure-Nak the option, suggesting its own
  1368.       protocol for use.  If a spanning tree protocol is not agreed upon,
  1369.       except for the case in which one system does not support any
  1370.       spanning tree protocol, the Bridging Control Protocol MUST NOT
  1371.  
  1372.  
  1373.  
  1374. Baker & Bowen            expires in six months                 [Page 24]
  1375. DRAFT                         PPP Bridging                  October 1993
  1376.  
  1377.  
  1378.       enter the Opened state.
  1379.  
  1380.       Most systems will only participate in a single spanning tree
  1381.       protocol.  If a system wishes to participate simultaneously in
  1382.       more than one spanning tree protocol, it MAY include all of the
  1383.       appropriate protocol types in a single Spanning-Tree-Protocol
  1384.       Configuration Option.  The protocol types MUST be specified in
  1385.       increasing numerical order.  For the purpose of comparison during
  1386.       negotiation, the protocol numbers MUST be considered to be a
  1387.       single number.  For instance, if System A includes protocols 01
  1388.       and 03 and System B indicates protocol 03, System B should
  1389.       Configure-Nak and indicate a protocol type of 03 since 0103 is
  1390.       greater than 03.
  1391.  
  1392.       By default, an implementation MUST either support the IEEE 802.1D
  1393.       spanning tree or support no spanning tree protocol.  An
  1394.       implementation that does not support any spanning tree protocol
  1395.       MUST silently discard any received IEEE 802.1D BPDU packets, and
  1396.       MUST either silently discard or respond to other received BPDU
  1397.       packets with an LCP Protocol-Reject packet.
  1398.  
  1399.    A summary of the Spanning-Tree-Protocol Option format is shown below.
  1400.    The fields are transmitted from left to right.
  1401.  
  1402.     0                   1                   2                   3
  1403.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
  1404.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1405.    |     Type      |    Length     |  Protocol 1   |  Protocol 2   | ...
  1406.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1407.  
  1408.  
  1409.    Type
  1410.  
  1411.       7
  1412.  
  1413.    Length
  1414.  
  1415.       2 octets plus 1 additional octet for each protocol that will be
  1416.       actively supported.  Most systems will only support a single
  1417.       spanning tree protocol, resulting in a length of 3.
  1418.  
  1419.    Protocol n
  1420.  
  1421.       Each Protocol field is one octet and indicates a desired spanning
  1422.       tree protocol.  Up-to-date values of the Protocol field are
  1423.       specified in the most recent "Assigned Numbers" RFC [4].  Current
  1424.       values are assigned as follows:
  1425.  
  1426.  
  1427.  
  1428.  
  1429. Baker & Bowen            expires in six months                 [Page 25]
  1430. DRAFT                         PPP Bridging                  October 1993
  1431.  
  1432.  
  1433.  
  1434.            Value     Protocol
  1435.  
  1436.              0       Null (no Spanning Tree protocol supported)
  1437.              1       IEEE 802.1D spanning tree
  1438.              2       IEEE 802.1G extended spanning tree protocol
  1439.              3       IBM Source Route Spanning tree protocol
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458.  
  1459.  
  1460.  
  1461.  
  1462.  
  1463.  
  1464.  
  1465.  
  1466.  
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484. Baker & Bowen            expires in six months                 [Page 26]
  1485. DRAFT                         PPP Bridging                  October 1993
  1486.  
  1487.  
  1488.    A.  Tinygram-Compression Pseudo-Code
  1489.  
  1490.       PPP Transmitter:
  1491.  
  1492.       if (ZeroPadCompressionEnabled &&
  1493.           BridgedProtocolHeaderFormat == IEEE8023 &&
  1494.           PacketLength == Minimum8023PacketLength) {
  1495.        /*
  1496.         * Remove any continuous run of zero octets preceding,
  1497.         * but not including, the LAN FCS, but not extending
  1498.         * into the MAC header.
  1499.         */
  1500.           Set (ZeroCompressionFlag);            /* Signal receiver */
  1501.           if (is_Set (LAN_FCS_Present)) {
  1502.               FCS = TrailingOctets (PDU, 4);    /* Store FCS */
  1503.               RemoveTrailingOctets (PDU, 4);    /* Remove FCS */
  1504.               while (PacketLength > 14 &&       /* Stop at MAC header or */
  1505.                      TrailingOctet (PDU) == 0)  /*  last non-zero octet */
  1506.                   RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
  1507.               Appendbuf (PDU, 4, FCS);          /* Restore FCS */
  1508.           }
  1509.           else {
  1510.               while (PacketLength > 14 &&       /* Stop at MAC header */
  1511.                      TrailingOctet (PDU) == 0)  /*  or last zero octet */
  1512.                   RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
  1513.           }
  1514.       }
  1515.  
  1516.       PPP Receiver:
  1517.  
  1518.       if (ZeroCompressionFlag) {                /* Flag set in header? */
  1519.        /* Restoring packet to minimum 802.3 length */
  1520.           Clear (ZeroCompressionFlag);
  1521.           if (is_Set (LAN_FCS_Present)) {
  1522.               FCS = TrailingOctets (PDU, 4);   /* Store FCS */
  1523.               RemoveTrailingOctets (PDU, 4);   /* Remove FCS */
  1524.               Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
  1525.               Appendbuf (PDU, 4, FCS);         /* Restore FCS */
  1526.           }
  1527.           else {
  1528.               Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
  1529.           }
  1530.       }
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.  
  1539. Baker & Bowen            expires in six months                 [Page 27]
  1540. DRAFT                         PPP Bridging                  October 1993
  1541.  
  1542.  
  1543.    Security Considerations
  1544.  
  1545.       Security issues are not discussed in this memo.
  1546.  
  1547.  
  1548.    References
  1549.  
  1550.       [1]   IBM, "Token-Ring Network Architecture Reference," 3rd
  1551.             edition, September 1989.
  1552.  
  1553.       [2]   IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging,"
  1554.             P802.1G/D7, December 30, 1992.
  1555.  
  1556.       [3]   IEEE 802.1, "Media Access Control (MAC) Bridges," ISO/IEC
  1557.             15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993.
  1558.  
  1559.       [4]   Reynolds, J. and J. Postel, "Assigned Numbers," RFC 1340,
  1560.             July 1992.
  1561.  
  1562.       [5]   Simpson, W. A., "PPP LCP Extensions," work in progress.
  1563.  
  1564.       [6]   Simpson, W. A., "The Point-to-Point Protocol (PPP)," work in
  1565.             progress.
  1566.  
  1567.       [7]   Sklower, Keith, "A Multilink Protocol for Synchronizing the
  1568.             Transmission of Multi-protocol Datagrams," work in progress,
  1569.             August 1993.
  1570.  
  1571.  
  1572. Acknowledgments
  1573.  
  1574.    This document is a product of the Point-to-Point Protocol Extensions
  1575.    Working Group.
  1576.  
  1577.    Special thanks go to Steve Senum of Network Systems, Dino Farinacci
  1578.    of 3COM, Rick Szmauz of Digital Equipment Corporation, and Andrew
  1579.    Fuqua of IBM.
  1580.  
  1581.  
  1582. Chair's Address
  1583.  
  1584.    The working group can be contacted via the current chair:
  1585.  
  1586.       Fred Baker
  1587.       Advanced Computer Communications
  1588.       315 Bollay Drive
  1589.       Santa Barbara, California  93117
  1590.  
  1591.  
  1592.  
  1593.  
  1594. Baker & Bowen            expires in six months                 [Page 28]
  1595. DRAFT                         PPP Bridging                  October 1993
  1596.  
  1597.  
  1598.       EMail: fbaker@acc.com
  1599.  
  1600.  
  1601. Author's Address
  1602.  
  1603.    Questions about this memo can also be directed to:
  1604.  
  1605.       Rich Bowen
  1606.       International Business Machines Corporation
  1607.       P O Box 12195
  1608.       Research Triangle Park, NC  27709
  1609.  
  1610.       Phone: (919) 543-9851
  1611.       EMail: rkb@ralvm11.vnet.ibm.com
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626.  
  1627.  
  1628.  
  1629.  
  1630.  
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649. Baker & Bowen            expires in six months                 [Page 29]
  1650. DRAFT                         PPP Bridging                  October 1993
  1651.  
  1652.  
  1653.                            TTTTaaaabbbblllleeee ooooffff
  1654. CCCCoooonnnntttteeeennnnttttssss
  1655.  
  1656.  
  1657.      1.     Historical Perspective ................................    1
  1658.  
  1659.      2.     Methods of Bridging ...................................    1
  1660.         2.1       Transparent Bridging ............................    1
  1661.         2.2       Remote Transparent Bridging .....................    2
  1662.         2.3       Source Routing ..................................    3
  1663.         2.4       Remote Source Route Bridging ....................    3
  1664.         2.5       SR-TB Translational Bridging ....................    4
  1665.  
  1666.      3.     Traffic Services ......................................    4
  1667.         3.1       LAN Frame Checksum Preservation .................    4
  1668.         3.2       Traffic having no LAN Frame Checksum ............    4
  1669.         3.3       Tinygram Compression ............................    5
  1670.         3.4       LAN Identification ..............................    5
  1671.  
  1672.      4.     A PPP Network Control Protocol for Bridging ...........    8
  1673.         4.1       Sending Bridge Frames ...........................    9
  1674.            4.1.1  Maximum Receive Unit Considerations .............    9
  1675.            4.1.2  Loopback and Link Quality Monitoring ............    9
  1676.            4.1.3  Message Sequence ................................    9
  1677.            4.1.4  Separation of Spanning Tree Domains .............   10
  1678.         4.2       Bridged LAN Traffic .............................   11
  1679.         4.3       Spanning Tree Bridge PDU ........................   15
  1680.  
  1681.      5.     BCP Configuration Options .............................   17
  1682.         5.1       Bridge-Identification ...........................   18
  1683.         5.2       Line-Identification .............................   19
  1684.         5.3       MAC-Support .....................................   20
  1685.         5.4       Tinygram-Compression ............................   21
  1686.         5.5       LAN-Identification ..............................   22
  1687.         5.6       MAC-Address .....................................   23
  1688.         5.7       Spanning-Tree-Protocol ..........................   24
  1689.  
  1690.         APPENDICES ................................................   27
  1691.  
  1692.         A.     Tinygram-Compression Pseudo-Code ...................   27
  1693.  
  1694.         SECURITY CONSIDERATIONS ...................................   28
  1695.  
  1696.         REFERENCES ................................................   28
  1697.  
  1698.      ACKNOWLEDGEMENTS .............................................   28
  1699.  
  1700.      CHAIR'S ADDRESS ..............................................   28
  1701.  
  1702.  
  1703.  
  1704.  
  1705. Baker & Bowen            expires in six months                 [Page ii]
  1706. DRAFT                         PPP Bridging                  October 1993
  1707.  
  1708.  
  1709.      AUTHOR'S ADDRESS .............................................   29
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736.  
  1737.  
  1738.  
  1739.  
  1740.  
  1741.  
  1742.  
  1743.  
  1744.  
  1745.  
  1746.  
  1747.  
  1748.  
  1749.  
  1750.  
  1751.  
  1752.  
  1753.  
  1754.  
  1755.  
  1756.  
  1757.  
  1758.  
  1759.  
  1760.